home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HyperLib 1997 Winter - Disc 1
/
HYPERLIB-1997-Winter-CD1.ISO.7z
/
HYPERLIB-1997-Winter-CD1.ISO
/
オンラインウェア
/
COM
/
Suntar 2.0.4 folder.sit
/
Suntar 2.0.4 folder
/
Suntar 2.0.4
/
speed tests
< prev
next >
Wrap
Text File
|
1994-11-01
|
8KB
|
213 lines
Times (in seconds) on a Macintosh LC with 40MB hard drive (access time 26 msec)
When not specifed, the times are with almost all INITs disabled
(there where only a couple which load themselves before the INIT manager
and SuperClock, which was used to measure speeds by subtracting the
initial and final times)
・・・・un-BinHex (ram disk -> hard disk, 900k file)
ZipIt: an error message and the extraction failed
suntar 1.1 (.hqx.tar) 210 sec (the slowest unBinHexer in the world...)
deHQX 2.0 150 sec (ram-ram) 175 sec (HD->HD)
Stuffit 1.5.1 146 sec
suntar 1.2.1 137 sec (I carefully optimized the algorithm, but unfortunately
that was not the bottleneck)
Stuffit Deluxe 3 125 sec
Downline 1.1 125 sec
BinHex 4.0 90 sec
Compact Pro 1.3.3 49 sec (with or without INITs: no event handling, no background
operation, the Macintosh does nothing else until the extraction
finished: I never liked this way to speed up an application)
suntar 1.3.3 43 sec (48 with INITs) (introduced disk buffering, and the
optimizations introduced in 1.2 may now show their strength)
BinHqx DA (32k buffer size) 36 sec (38 with INITs)
suntar 2.0 33 sec (36 with INITs) (uses a look-up table to compute the
CRC error checking: pole position !!!)
・・・・compressed PackIt extraction (ram disk -> hard disk, 900k file)
Downline: an error message and the extraction failed
PackIt III 315 sec (320 sec with INITs)
suntar 1.2.1 156 sec (175 sec with INITs)
Stuffit Deluxe 3 130 sec
Stuffit 1.5.1 120 sec
unpit 0.1 105 sec
unpit 0.3 (compiled with Think C 5, I had the source but could not find the application)
100 sec
suntar 1.3.3 88 sec (no change to the algorithm, but benefits from I/O buffering)
suntar 2.0 beta 8 66 sec (uhh, in suntar 1.3 I'd forgotten to fully enable buffering !
And obviously the faster CRC routine helps)
suntar 2.0 42 sec (optimized the routine: it's not nice being
proud of something which I knew was not the
best I could do)
・・・・non-compressed PackIt extraction (ram disk -> hard disk, 900k file)
PackIt III 225 sec
suntar 1.2.1 100 sec
StuffIt 1.5.1 65 sec
StuffIt Deluxe 65 sec
suntar 1.3.3 40 sec
unpit 0.1 29 sec
unpit 0.3 28 sec
Downline 23 sec
suntar 2.0 b8 18 sec (the gain from 1.3.3 to 2.0 b8 is 22 sec: same file, same gain)
suntar 2.0 12 sec
・・・・tar extraction (floppy disk->ram disk, a directory with many files,
end of archive at sector 2556)
suntar 1.1 140 sec (187 with INITs)
suntar 1.2.1 140 sec (185)
StuffIt Deluxe (.tar file on a HFS floppy) 75 sec (+16 for reading
the directory + the time to select all the files in the scrolling list)
tar 3.0 51 sec (59)
suntar 2.0 51 sec (58) (the accuracy of measurements can't guarantee a
1 sec difference but suntar 2.0 performs some tests
to identify long pathnames and it is reasonable
to expect a small speed decrement over 1.3.3)
suntar 1.3.3 50 sec (56)
(suntar 2.0: save sectors 0 to 2556 36 sec, Copy disk archive to file 47 sec)
・・・・tar extraction (file on hard disk->ram disk, 2556 sectors archive)
suntar 1.1 96 sec (138 sec with INITs)
suntar 1.2.1 92 sec (135 sec)
StuffIt Deluxe 3.0.6 30 sec (33 with INITs) (+5 to read the directory)
suntar 1.3.3 22 sec (28)
suntar 2.0 22 sec (27)
tar 3.0 18 sec (21)
・・・・tar extraction (HD->HD, 900k file)
suntar 1.1 92 sec
suntar 1.2.1 90 sec
untar 1.0 60 sec (it's a new program and I did not perform other tests on it)
StuffIt Deluxe 21 sec
suntar 1.3.3 17 sec
suntar 2.0 17 sec
tar 3.0 12 sec
・・・・uudecode (ram disk -> hard disk, 900k file)
uulite 1.3 300 sec (what a pity, its user interface is very good, but so slowノ)
UMCPェ Tools 95 sec
tiger 65 sec (ram->ram) 120 sec (HD->HD)
un*files (bug fixed and recompiled with ThC 4) 55 sec (ram->ram) 105 sec (HD->HD)
StuffIt Deluxe 46 sec
suntar 2.0 29 sec
uuparse 23 sec
uutool 2.32 20 sec
・・・・uuencode (another file, HD->HD)
uulite 1.6 220 sec
StuffIt Deluxe 29 sec
suntar 2.03 14 sec
UUTool 2.32 12 sec
UUparser 1.7.1 12 sec
・・・・Macbinary extraction (HD->HD, 900k file)
UMCPェ Tools 100 sec
suntar 1.2.1 96 sec
BinHex 5.0 29 sec
StuffIt Deluxe 24 sec
MacBinary II+ 17 sec
suntar 1.3.3 17 sec
suntar 2.0 17 sec
suntar 2.0 (with double-sized buffers) 14 sec
MacBinary 1.01 12 sec
ZipIt 7 sec (but in a different configuration, also suntar was
a couple of seconds faster that day. Since ZipIt is a large program,
probably it uses a huge buffer)
・・・・tar creation (HD->ram disk, 700k directory)
StuffIt Deluxe 28 sec
suntar 2.0 24 sec
tar 3.0 21 sec
・・・・tar creation (HD->HD, 900k file)
StuffIt Deluxe 17 sec
suntar 2.0 16 sec
tar 3.0 12 sec
・・・・tar creation (HD->floppy disk, 700k directory)
suntar 1.1 400 sec
suntar 1.2.1 360 sec
StuffIt Deluxe (file on a Mac floppy disk) 125 sec
tar 3.0 49 sec
suntar 1.3.3 45 sec (buffered only towards the floppy)
suntar 2.0 42 sec
・・・・BinHex creation (HD->ram, 900k file)
StuffIt 1.5.1 128 sec
StuffIt Deluxe 110 sec
Downline 95 sec
BinHex 4.0 92 sec
BinHqx DA 51 sec
Compact Pro 47 sec
suntar 2.0 29 sec
・・・・MacBinary creation (HD->HD, 900k file)
UMCPェ Tools 100 sec
suntar 2.0 b8 35 sec (buffered towards the destination but not the source)
BinHex 5.0 29 sec
StuffIt Deluxe 26 sec
MacBinary II+ 17 sec
suntar 2.0 15 sec
MacBinary 1.01 13 sec
If you are a programmer and you want to write fast code, this is what
I learnt in the process of speeding up suntar:
1) I/O buffering is always essential: I believe that in many categories
the faster is the program which uses the largest buffer. In fact, since
some programs (including suntar) allow you to choose the buffer size,
in most cases it's meaningless to look for "the fastest" program,
that depends on how they are configured. The large jumps in the
times (e.g. a factor of 2) between two programs are always
due to different buffering schemes (e.g.: read one char at a time,
512 bytes, 8k or more). But there is a point at which increasing the
buffer gets no increase in speed, which depends on the device: for a
hard disk 8k is good, for a floppy disk it's better 9k (that's a
track or half track on 720k or 1440k floppy disks), and very large
buffers are still useful for an extraction to the same device if
the source file and the destination file are placed at different
positions and a large head movement is required every time the
application loads or flushes a buffer.
2) only for complex conversions, at least for operations on fast disks,
it's important a well optimazed algorithm, where most operations
are done inside a single loop within a single function, with all
essential variables kept in registers.
3) for very simple formats (MacBinary, non-compressed PackIt, tar)
it's important to handle one format only: suntar suffers from its
number of supported formats, StuffIt Deluxe suffers even more
(I mean that it's possible and easy to be 50% faster than suntar
in uncompressed PackIt extraction, no program does that only
because the PackIt format is obsolete and the original
PackIt is outperformed anyway also by non-optimized programs).
4) only if the algorithm should contain some code written by a
Mathematician, some knowledge of Mathematics is not bad
(Mathematicians usually write straighforwardly and never worry
about speed, but in order to rewrite their code you must understand
what they're doing).
5) assembly language is useful, but only in special cases: e.g. mcopy
is three times faster than a standard memcpy, but it would be almost
as fast written in C: it's the smart algorithm which makes it fast.
Assembly language is really essential only if you need instructions
which the C compiler does not exploit (DBRA, SWAP, BTST, all the
operations involving the processor flags) or exceptionally when you
need more register variables than the compiler supports.
6) never forget to measure the speed and compare it to other programs:
one may believe to have written a wonderfully fast program and then
discover that a small detail makes it slow.
1 November 1994
Gabriele Speranza